Note: This video and podcast were generated using AI, adapting the original content and technical insights created by the author of the blog.

Until recently, software delivery benefited from something few organizations ever recognized as part of a security process: time. A developer would finish a change and open a pull request and a teammate might review it later that afternoon. Automated tests would run, security findings would be investigated, and uncertainties could be discussed before the next scheduled release. 

The process wasn’t always flawless, but there was usually enough space between writing code and deploying it for people to catch what the system couldn’t. However, AI is steadily removing that margin for error.

Today, software can be generated, modified, tested, and deployed faster than many organizations can assess the risks it could introduce. The result isn’t a new category of security problems because the vulnerabilities, operational shortcuts, and governance gaps were already there. AI simply compresses the time between cause and consequence until the problems become impossible to ignore.

That realization crystallized during the IT Security Summit in Berlin earlier this summer. Two talks in particular helped me understand what this acceleration means for secure software delivery: one by Bea Hughes, who has worked for 25 years in infrastructure security, and another by Sven Schuetz, who has more than 20 years of experience in the IT industry. Although they approached the issue from different perspectives, their insights point toward the same conclusion: companies must turn engineering judgment into automated guardrails instead of continuing to rely primarily on manual decisions and processes.

Most debates around AI focus on how much faster developers can produce software, or whether autonomous agents can replace parts of the engineering workflow. Those are worthwhile topics, but they skip an uncomfortable one: AI isn’t changing the rules of secure software delivery; it’s exposing which organizations were actually following them. In other words, the problem isn’t necessarily that AI moves too fast, but that many of the safeguards modern engineering relied on weren’t designed to operate at AI speed. To understand why those safeguards are now under pressure, we first need to examine what made them work before AI changed things. 

What Kept Software Secure Before AI Speed? 

Secure software delivery was already evolving long before generative AI entered the workflow. Organizations had spent years moving security closer to development, increasing visibility into dependencies, automating scans, and formalizing release decisions. These efforts addressed real problems, but they shared a limitation: they often improved the ability to identify risks faster than the ability to resolve them.

“Shift left” is a clear example. The objective was to find security issues earlier, when they were easier to fix, and make developers part of the security process. In practice, however, running security scans earlier and surfacing their findings directly within pull requests didn’t automatically make those findings useful or actionable.

In reality, what happened can be summarized like this: a developer opening a dashboard to find dozens, perhaps hundreds, of warnings marked in red. Some identified genuine production risks. Others were duplicates, low-priority issues, or vulnerabilities that could not be exploited in that particular system. Yet the interface often gave little indication of which was which and the sheer amount of notifications was overwhelming. Faced with this wall of alerts, the most understandable response was not immediate action but hesitation: close the window, get a coffee, and return to the code that already had a deadline. 

As Bea Hughes argues, “We’ve shifted left, and all the problems are now on the developer… They have absolutely no idea what to prioritize, or how to go about fixing it.” 

Developers received more information than they could realistically interpret, without enough context to know which findings mattered, whether they were exploitable, or what to do next. Visibility without prioritization became another form of workload. 

Why Didn’t Better Visibility Mean Better Security? 

Software Bills of Materials followed a similar pattern. SBOMs gave organizations a clearer inventory of the components inside their software, which was necessary in systems built from open-source packages, containers, and layered dependencies. But, as Hughes sarcastically notes, an inventory list is not the same as maintenance: “We solved security five years ago because someone invented SBOMs. Because the hardest bit in security was finding the list of software we had on everything and never patching it ….” Her point, of course, is the opposite: knowing which components are present does little to improve security if organizations fail to update them. SBOMs can show what is present, but they can’t update a dependency, test if the replacement worked, or determine whether a reported vulnerability was actually reachable. 

Vulnerability scanners created a similar gap: teams became better at counting findings than removing them.  Organizations were aware of this gap and they knew their findings outpaced their fixes. But closing that gap and actually implementing the fixes wasn’t such an urgent task because there was time to do it. 

The safeguards were incomplete (a vulnerability could sit unpatched, an SBOM could go unread), but the relatively slow pace of software delivery made those shortcomings manageable before issues became a real emergency. AI is now removing that time buffer.

What Held the System Together: Human Judgment and Mature Engineering Practices 

Release governance had its own version of this problem. Change Advisory Boards brought experienced people into deployment decisions and created a formal point of accountability. But they still depended on a manageable pace of change. Reviewers needed enough time to examine the available evidence, understand the context, discuss uncertainty, and make a decision before the next change demanded their attention.

That model worked best when human judgment was supported by mature engineering practices. Automated testing, reliable delivery pipelines, dependency management, operational monitoring, and rapid feedback reduced uncertainty before a change ever reached a review board. The stronger these practices were, the less often reviewers had to compensate for missing information or weak controls.

Sven Schuetz points to this relationship through the DORA metrics: lead time, deployment frequency, change failure rate, and recovery time. These measures are sometimes treated as competing goals, as though faster delivery must inevitably produce more failures. But Schuetz argues that this is not what happens in well-performing teams. “For well-performing teams, actually all of those metrics […] move along together,” he notes.

In other words, high-performing teams do not achieve speed by weakening testing, maintenance, or operational readiness. They become faster because those capabilities reinforce one another. Reliable testing supports more frequent deployment, better monitoring enables faster recovery, strong dependency management reduces the likelihood of failure. Human review remains part of the system, but it sits on top of practices that have already removed much of the uncertainty.

AI makes these practices more important, not less. Yet even mature delivery systems were built on the assumption that people would be able to keep pace with the changes moving through it. However, as AI increases both their volume and speed, that assumption begins to break down. 

How Exactly Did AI Break the Time Buffer?

AI places the assumption under pressure because it compresses the interval between creation, review, and consequence. Manual review has long been the final safety net: developers inspect pull requests, security teams assess findings, and release boards discuss changes before production.

That same imbalance appears in vulnerability management. AI can accelerate discovery, but it doesn’t automatically accelerate remediation. Here, we can turn back to Hughes, who explains what AI does clearly: “We still have a big list of vulnerabilities… and no real easy path to fixing most of them, and they’re only gonna get more as AI discovers more CVEs [Common Vulnerabilities and Exposures]  than anything else ever.” Finding problems becomes easier, but keeping pace with them doesn’t. 

Across these examples, AI rarely invents an entirely new kind of failure. Instead, it accelerates familiar ones: 

• Weak validation reaches production sooner.
• Over-permissioned systems become dangerous faster.
• Vulnerability discovery outpaces remediation.
• Review queues exceed human capacity.
• Informal safeguards have less time to intervene. 

That is why the next phase of secure delivery is not about producing still more findings or adding another checkpoint. The real constraint is in interpretation, prioritization, and verification—tasks that still depend largely on human judgment and that can’t scale at the same pace as AI-generated change. The challenge is, therefore, to embed those capabilities directly into the delivery system itself.

Learn more: To take part in the conversation about how AI is changing secure software delivery, join industry experts at the IT Security Summit in Munich from November 30 to December 4.

• No, we can’t do CD in this “AI” age – Kris Buytaert – o11y
• May the Code Be Secure: The Role of AI in Shaping the Future of DevSecOps – Mike van der Bijl – DHL
• Workshop: Secure Your GitHub Pipeline – Integrating Open Source Security Checks – Christian Schneider – Schneider IT Security

What Does It Mean to Build Security Into the System? 

Building security into the system means designing the software delivery process so that it manages risk consistently, rather than depending on individual human judgement. This can involve automation, mandatory verification, or policies that deliberately constrain how quickly changes enter the system.

The first approach is to automate the initial risk assessment. In software delivery, this could mean replacing repetitive approval meetings with a risk-prediction system that identifies routine changes and directs human attention toward the exceptions. As Schuetz puts it: “When the risk prediction engine says that […] that’s a very low-risk change and there’s probably not going to be a problem with that, then why would any human still have to look at that?” The purpose is to use human judgement selectively. Instead of spreading attention evenly across every deployment, organizations can concentrate it on the smaller number of changes where risk remains uncertain. 

The second approach is to make verification an integral part of the delivery process. Hughes argues that teams should test the build artifact they are actually preparing to deploy, rather than assuming that tests performed on the source code are sufficient. As she puts it, “You should be really testing your build artifacts before you ship them off rather than just going, ‘The tests passed for the code. I then shove them in a container.’” The point here is not primarily to predict risk, but to verify the actual product of the build before it reaches production. 

Dependency management requires a different kind of control and provides, therefore, a good example of a third approach. Minimum release-age policies prevent newly published packages from entering a build immediately. Rather than testing or assessing the package at once, the policy creates a deliberate time buffer. That delay gives maintainers and users an opportunity to uncover malicious, compromised, or broken releases before the organization adopts them. 

These mechanisms are related, but they do different work. Automated risk assessment prioritizes human attention, artifact testing verifies what will actually be deployed, and minimum release-age policies reduce exposure by delaying adoption. Together, they show that building security into the system is not one technique, but a practice of making risk management a repeatable property of the delivery process. As AI increases the speed and volume of software change, that repeatability becomes essential because security controls must be able to scale without requiring human oversight to grow at the same rate. 

AI Agents Need Safety Nets Too

The shift from relying on a single point of judgment to distributing responsibility across the system becomes even more important when AI agents are given room to act on their own.

The response is usually layered instead of singular. This is often described through the “Swiss cheese model” of accident prevention. In the model, every safeguard is represented as a slice of Swiss cheese. Each slice blocks some risks, but each also contains holes: the weaknesses or blind spots. An incident occurs when the holes in several layers align, allowing a threat to pass through every defense. The goal is, therefore, to combine several imperfect controls so that the weakness of one layer is covered by the strengths of another.

At this point, it’s worth bringing in the perspective of Lothar Schulz, a secure software delivery expert, who applies this model directly to the risks posed by AI agents. He argues that those risks must be contained through several complementary controls: sandboxing limits what an agent can access, scoped permissions restrict what it can change, input and output filtering helps detect prompt injection and unsafe responses, while network restrictions isolate sensitive systems. Each measure addresses a different failure mode. 

None of these layers is foolproof. As Schulz explains, “Some of the risks you will mitigate with that layer. But because Swiss cheeses have holes, some other risks may slip through that layer, and then you think of another layer.” Human review, then, becomes the final safeguard for cases that the automated controls can’t confidently assess or solve. This allows humans to focus their limited attention where their judgement is genuinely required and most valuable. 

Learn more: You can deep dive into the next phase of secure software delivery and what it will entail at the IT Security Summit in Munich from November 30 to December 4.

• Secure Intelligence: OWASP Top Ten(s) for AI – Christian Wenz – Arrabiata Solutions
• Secretless AI – How to Deploy AI Agents Without Exposing your Secrets – Martin Gegenleitner – Thales Group
• Additional AuthZ Checks with Infrastructure Components – Michael Hofmann – Hofmann IT-Consulting

From Automated Checks to Engineered Trust 

AI generates possibilities and engineering provides confidence. This brings us back to where we began. Some people like to see AI as a force that is rewriting software engineering, but perhaps the more interesting story is that AI is acting like a stress test.

It is exposing every place where secure software delivery quietly depended on time, manual effort, institutional memory, or individual diligence. It is revealing which controls were genuine engineering practices and which were simply habits that happened to work because software moved slowly enough for people to compensate.

That is why the future of secure software delivery is unlikely to be defined by larger models or faster code generation alone. It will be defined by something far less glamorous: whether organizations can take the engineering judgment that once relied too heavily on people, meetings, and checklists and encode it directly into the systems that build, test, approve, and operate software. This doesn’t remove people from the process. Instead, it frees them to focus on the decisions that require genuine judgment and for which they must ultimately remain accountable. In other words, AI isn’t forcing the industry to invent an entirely new discipline. It’s forcing it to finally practice the one it has been advocating all along.

How Are Security Teams Preparing for AI-Accelerated Delivery? 

Those are the challenges at the center of the IT Security Summit in Munich. Across four days of workshops and technical sessions, security practitioners, developers, architects, and technology leaders examine practical approaches to protecting modern software systems: from Secure Coding and the Software Development Lifecycle to threat detection, infrastructure defense, and AI-Powered Security Automation. The emphasis is on connecting strategy with implementation and turning security principles into practices that can withstand real-world pressure.

The future of secure software delivery appears to depend less on adding more manual controls and more on engineering trust directly into the delivery process. The IT Security Summit offers an opportunity to see how that transition is already taking place in practice. The event runs from November 30 to December 4 in Munich and brings together people who are developing, testing, and applying security models for the AI era.